Date: Sun, 1 Aug 93 21:13:21 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #226 

To: packet-radio 


Packet-Radio Digest Sun, 1 Aug 93 Volume 93 : Issue 226 


Today's Topics: 
BayComm and BayPac Modems 
FBB Server Help 
Guide to the Personal Radio Newsgroups 
HF Packet 
INTERNET & FIDONET links to Amateur Packet (2 msgs) 
Is rec.radio.amateur.packet about to die? Read on. (3 msgs) 
TCP/IP via radio link? 

X1J and the DR200 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Fri, 30 Jul 1993 07:45:56 +0000 

From: news!demon!imcldn.demon.co.uk!mike@uunet.uu.net 
Subject: BayComm and BayPac Modems 

To: packet-radio@ucsd.edu 


In article <9307271926.AA05597@golden-grahams> taalebi@ai.mit.EDU writes: 


>Hello there. 

I wonder if anyone has used any of these modems: 
BayCom 

for software-based TNC's? 


Your comments on their performance will be appreciated. 
I would specially like to know about their KISS mode capabilitis and 


> 
> 
> 
> 
> 
> 
> baud rate limits. 


I use a Baycom Modem, with the TFPCX driver, and the F6FBB BBS Software as 
a PMS, runns 20 channels in theory, I have had it up to 5 simultaneous user 
connections, and 3 forwarding sessions though... 
Mike Simkins G7OBS @ G70BS.GB7DAA.##33.GBR.EU (Packet) 

g7obs @ imcldn.demon.co.uk (Internet) 


Date: Fri, 30 Jul 1993 20:45:39 +0000 

From: news!demon!g1xgp.demon.co.uk! g1xgp@uunet.uu.net 
Subject: FBB Server Help 

To: packet-radio@ucsd.edu 


Hi folks, 

I am running FBB and paket. Is there a Server available for FBB where a 
YAPP download can be posted to a Private File Area, which can be viewed 
by the SysOp only, and then posted to FBB/YAPP for general uploading. 
This facility is available with paket. 


73's Steve GILXGP 


+ Steve Blinkhorn + G1XGP @ GB7DUG.#32.GBR.EU (Amateur Radio) + 
+ AMPRnet + g1xgp@g1xgp.ampr.org [44.131.16.147] + 
+ Essex Packet Group + g1xgp@g1xgp.demon.co.uk (Internet) + 


Date: Sun, 1 Aug 1993 16:41:06 GMT 

From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!wupost! 
crcnis1.unl.edu!news.unomaha. edu! news@network.ucsd.edu 

Subject: Guide to the Personal Radio Newsgroups 

To: packet-radio@ucsd.edu 


Posted-By: auto-faq 2.4 

Archive-name: radio/personal-intro 

Revision: 1.4 06/30/93 12:04:14 

Changes: new rec.radio.amateur.* newsgroups, cs.utexas.edu gateway 


(Note: The following is reprinted with the permission of the author. 
Due to the recent reorganization, it is also on a temporarily- 
accelerated posting schedule as follows: 


July weekly 
August bi-weekly 


September back to monthly) 


This message describes the rec.radio.amateur.*, rec.radio.cb, rec.radio.info, 
and rec.radio.swap newsgroups. It is intended to serve as a guide for the new 
reader on what to find where. Questions and comments may be directed to the 
author, Jay Maynard, K5ZC, by Internet electronic mail at 
jmaynard@oac.hsc.uth.tmc.edu. This message was last changed on 30 June 1993 to 
add the groups created during the latest reorganization vote and the 
description of the cs.utexas.edu gateway. 


History 


Way back when, before there was a Usenet, the Internet hosted a mailing list 
for hams, called (appropriately enough) INFO-HAMS. Ham radio discussions 
were held on the mailing list, and sent to the mailboxes of those who had 
signed up for it. When the Usenet software was created, and net news as we 
now know it was developed, a newsgroup was created for hams: net.ham-radio. 
The mailing list and the newsgroup were gatewayed together, eventually. 


As the net grew, and as packet radio came into vogue, packet discussion began 
to dominate other topics in the group and on the list. This resulted in the 
logical solution: a group was created to hold the packet discussion, and 
another corresponding mailing list was created as well: net.ham-radio.packet 
and PACKET-RADIO, respectively. 


These two groups served for several years, and went through Usenet's Great 
Renaming essentially unchanged, moving from net.ham-radio[.packet] to 
rec.ham-radio[.packet]. Readership and volume grew with the rest of the 
network. 


The INFO-HAMS mailing list was originally run from a US Army computer at 
White Sands Missile Range, SIMTEL20. There were few problems with this 
arrangement, but one was that the system was not supposed to be used for 
commercial purposes. Since one of hams' favorite pastimes is swapping 
gear, it was natural for hams to post messages about equipment for sale 

to INFO-HAMS/rec.ham-radio. This ran afoul of SIMTEL20's no-commercial-use 
restriction, and after some argument, a group was created specifically 

for messages like that: rec.ham-radio.swap. This group wasn't gatewayed to 
a mailing list, thus avoiding problems. 


While all this was happening, other folks wanted to discuss other aspects 
of the world of radio than the personal communications services. Those 
folks created the rec.radio.shortwave and rec.radio.noncomm newsgroups, 
and established the precedent of the rec.radio.* hierarchy, which in turn 
reflected Usenet's overall trend toward a hierarchical name structure. 


The debate between proponents of a no-code ham radio license and its opponents 


grew fierce and voluminous in late 1989 and 1990. Eventually, both sides grew 
weary of the debate, and those who had not been involved even more so. A 
proposal for a newsgroup dedicated to licensing issues failed. A later 
proposal was made for a group that would cover the many recurring legal issues 
discussions. During discussion of the latter proposal, it became clear that it 
would be desirable to fit the ham radio groups under the rec.radio.* 
hierarchy. A full-blown reorganization was passed by Usenet voters in January 
1991, leading to the overall structure we now use. 


After the reorganization, more and more regular information postings began to 
appear, and were spread out across the various groups in rec.radio.*. Taking 
the successful example of the news.answers group, where informational postings 
from across the net are sent, the group rec.radio.info was created in 
December, 1992, with Mark Salyzyn, VE6MGS, initially serving as moderator. 


In January, 1993, many users started complaining about the volume in 
rec.radio.amateur.misc. This led to a discussion about a second 
reorganization, which sparked the creation of a mailing list by Ian Kluft, 
KD6EUL. This list, which was eventually joined by many of the most prolific 
posters to the ham radio groups, came up with a proposal to add 11 groups to 
the rec.radio.amateur hierarchy in April 1993. The subsequent vote, held in 
May and early June, approved the creation of five groups: 
rec.radio.amateur.digital.misc (to replace .packet), .equipment, .homebrew, 
-antenna, and .space. 


The Current Groups 


I can hear you asking, "OK, so this is all neat history, but what does it 
have to do with me now?" The answer is that the history of each group has 
a direct bearing on what the group is used for, and what's considered 
appropriate where. 


The easy one is rec.radio.amateur.misc. It is what rec.ham-radio was renamed 
to during the reorganization. Any message that's not more appropriate in one 
of the other groups belongs here, from contesting to DX to ragchewing on VHF 
to information on becoming a ham. 


The group rec.radio.amateur.digital.misc is for discussions related to 
(surprise!) digital amateur radio. This doesn't have to be the common 
two-meter AX.25 variety of packet radio, either; some of the most 
knowledgeable folks in radio digital communications can be found here, and 
anything in the general area is welcome. The name was changed to emphasize 
this, and to encourage discussion not only of other text-based digital modes, 
such as AMTOR, RTTY, and Clover, but things like digital voice and video as 
well. The former group, rec.radio.amateur.packet, has not been removed as of 
this writing, but it is obsolete, and you should use .digital.misc instead. 
The group has the .misc as part of the name to allow further specialization if 


the users wish it, such as .digital.tcp-ip. 


The swap group is now rec.radio.swap. This recognizes a fact that became 
evident shortly after the original group was formed: Hams don't just swap ham 
radio gear, and other folks besides hams swap ham equipment. If you have radio 
equipment, or test gear, or computer stuff that hams would be interested in, 
here's the place. Equipment wanted postings belong here too. Discussions about 
the equipment generally don't; if you wish to discuss a particular posting 
with the buyer, email is a much better way to do it, and the other groups, 
especially .equipment and .homebrew, are the place for public discussions. 
There is now a regular posting with information on how to go about buying and 
selling items in rec.radio.swap; please refer to it before you post there. 


The first reorganization added two groups to the list, one of which is 
rec.radio.amateur.policy. This group was created as a place for all the 
discussions that seem to drag on interminably about the many rules, 
regulations, legalities, and policies that surround amateur radio, both 
existing and proposed. The neverending no-code debate goes here, as does 
the New Jersey scanner law, the legality of ordering a pizza on the 
autopatch, what a bunch of rotten no-goodniks the local frequency 
coordinating body is, and so on. 


The other added group is rec.radio.cb. This is the place for all discussion 
about the Citizens' Band radio service. Such discussions have been very 
inflammatory in rec.ham-radio in the past; please do not cross-post to both 
rec.radio.cb and rec.radio.amateur.* unless the topic is genuinely of interest 
to both hams and CBers - and very few topics are. 


The rec.radio.info group is just what its name implies: it's the place where 
informational messages from across rec.radio.* may be found, regardless of 
where else they're posted. As of this writing, information posted to the group 
includes Cary Oler's daily solar progagation bulletins, ARRL bulletins, the 
Frequently Asked Questions files for the various groups, and radio 
modification instructions. This group is moderated, so you cannot post to it 
directly; if you try, even if your message is crossposted to one of the other 
groups, your message will be mailed to the moderator, who is currently Mark 
Salyzyn, VE6MGS. The email address for submissions to the group is 
rec-radio-info@ve6émgs.ampr.ab.ca. Inquires and other administrivia should be 
directed to rec-radio-request@ve6mgs.ampr.ab.ca. For more information about 
rec.radio.info, consult the introduction and posting guidelines that are 
regularly posted to that newsgroup. 


The groups rec.radio.amateur.antenna, .equipment, .homebrew, and .space are 
for more specialized areas of ham radio: discussions about antennas, 
commercially-made equipment, homebrewing, and amateur radio space operations. 
The .equipment group is not the place for buying or selling equipment; that's 
what rec.radio.swap is for. Similarly, the .space group is specifically about 
amateur radio in space, such as the OSCAR program and SAREX, the Shuttle 


Amateur Radio EXperiment; other groups cover other aspects of satellites and 
space. Homebrewing isn't about making your own alcoholic beverages at home 
(that's rec.crafts.brewing), but rather construction of radio and electronic 
equipment by the amateur experimenter. 


The rec.radio.amateur.misc, .packet, and .policy groups, and the 
rec.radio.info group, are available by Internet electronic mail in digest 
format; send a mail message containing "help" on a line by itself to 
listserv@ucsd.edu for instructions on how to use the mail server. The 
rec.radio.swap group is not available for reading by electronic mail. At this 
writing, the most recently added groups are also not available for reading by 
electronic mail, although that may change. 


All of the groups can be posted to by electronic mail, though, by using a 
gateway at the University of Texas at Austin. To post a message this way, 
change the name of the group you wish to post to by replacing all of the '.'s 
with '-'s - for example, rec.radio.swap becomes rec-radio-swap - and send to 
that name@cs.utexas.edu (rec-radio-swap@cs.utexas.edu, for example). You may 
crosspost by including multiple addresses as Cc: entries (but see below). This 
gateway's continued availability is at the pleasure of the admins at 
UT-Austin, and is subject to going away at any time - and especially if 
forgeries and other net.abuses become a problem. You have been warned. 


A Few Words on Crossposting 


Please do not crosspost messages to two or more groups unless there is genuine 
interest in both groups in the topic being discussed, and when you do, please 
include a header line of the form "Followup-To: group.name" in your article's 
headers (before the first blank line). This will cause followups to your 
article to go to the group listed in the Followup-To: line. If you wish 

to have replies to go to you by email, rather than be posted, use the word 
"poster" instead of the name of a group. Such a line appears in the headers 

of this article. 


One of the few examples of productive cross-posting is with the rec.radio.info 
newsgroup. To provide a filtered presentation of information articles, while 
still maintaining visibility in their home newsgroups, the moderator strongly 
encourages cross-posting. All information articles should be submitted to the 
rec.radio.info moderator so that he may simultaneously cross-post your 
information to the appropriate newsgroups. Most newsreaders will only present 
the article once, and network bandwidth is conserved since only one article is 
propagated. If you make regular informational postings, and have made 
arrangements with the moderator to post directly to the group, please 
cross-post as appropriate. 


Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can 


jmaynard@oac.hsc.uth.tmc.edu | adequately be explained by stupidity. 
"If my car ran OS/2, it'd be there by now" -- bumper sticker 
GCS d++ p+ c++ 1+ m+/- s/++ g++ wtt+ t+ x 


73, Paul W. Schleck, KD3FU 
pschleck@unomaha. edu 


Celebrating 60 years of the Univ. of Maryland ARA - W3EAX (1933-1993) 


Date: Fri, 30 Jul 1993 20:05:42 GMT 

From: swrinde! gatech!howland.reston.ans.net!agate!linus!linus.mitre.org! 
mwvm.mitre.org!M16616@network.ucsd.edu 

Subject: HF Packet 

To: packet-radio@ucsd.edu 


A few words on the use and reliability of HF HAM Packet would be helpful. 
THANKS. :-) :-) 


Date: Fri, 30 Jul 1993 20:08:27 GMT 

From: swrinde!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!agate!linus! 
linus.mitre.org!mwvm.mitre.org!M16616@network.ucsd.edu 

Subject: INTERNET & FIDONET links to Amateur Packet 

To: packet-radio@ucsd.edu 


Various people have said that it is "no problem" to link Amateur Radio packet t 
o FIDONET and INTERNET. I would be interested in hearing from someone with 
hands on experience who does this routinely. Thanks. :-) :-) 


Date: 1 Aug 93 06:19:16 GMT 

From: pacbell.com!amdahl!amdahl!ikluft@ames.arpa 
Subject: INTERNET & FIDONET links to Amateur Packet 
To: packet-radio@ucsd.edu 


[Followups directed to rec.radio.amateur.digital.misc] 
M16616@mwvm.mitre.org writes: 


>Various people have said that it is "no problem" to link Amateur Radio packet 
>to FIDONET and INTERNET. I would be interested in hearing from someone with 


>hands on experience who does this routinely. 


Whatever you arrange, don't gate a Fidonet group into rec.radio.amateur. packet 
because it is being replaced by rec.radio.amateur.digital.misc. The packet 
newsgroup will be removed on Sept 21st. 


So, if you want to arrange a gateway to Fidonet, make sure you arrange a 
"digital amateur radio" discussion over there, not just packet radio. 


Ian Kluft KD6EUI PP-ASEL Amdahl Corporation, Open Systems Development 
ikluft@uts.amdahl.com Santa Clara, CA 
[disclaimer: any opinions expressed are mine only... not those of my employer] 


Date: Thu, 29 Jul 93 20:59:58 EST 

From: swrinde!cs.utexas.edu!uwm.edu!spool.mu.edu! torn! nott!cunews!revcan! balsam! 
pinetree! gordon@network.ucsd.edu 

Subject: Is rec.radio.amateur.packet about to die? Read on. 

To: packet-radio@ucsd.edu 


da884@cleveland.Freenet.Edu (David Toste) writes: 
The following USENET groups are being removed on the dates indicated. 
To help ease the transition, you might wish to mark them as "no local 


posting allowed" at your site, with the C News/INN flag "n" 


GROUP DATE SUPERSEDED BY 
NOTE: rec.radio.amateur. packet 0921 rec.radio.amateur.digital.misc 


Looks to me that the last day for this group is on Sept 21th~!!! 


What gives? 


VV VV VV VV VV WV 


As it clearly (I think) says, rec.radio.amateur.packet is going to be 
rmgroup'd on or near September 21. There was a CFV for a re-org of the 
rec.radio.amateur hierarchy and rec.radio.amateur.digital.misc was 
passed, meaning that rec.radio.amateur.packet is redundant because it 
falls under the definition of the new r.r.a.d.m group. 


Relax.... you'll still have a group to talk about packet in. 
--G 
Internet: gordon@pinetree.org | Guillotine operators 


UUCP: ...!pinetree! gordon | get severance pay. 


Packet: VE3XGD@VE3JF | * VE3XGD x* 
Gordon's Pinetree - Ottawa, Ontario, Canada - +1 613 526 0702 - v32bis/v42bis 


Date: 1 Aug 1993 21:54:03 GMT 

From: nothing.ucsd.edu! brian@network.ucsd.edu 

Subject: Is rec.radio.amateur.packet about to die? Read on. 
To: packet-radio@ucsd.edu 


Seems I overlooked an alternative that someone was kind enough to point 
out in mail to me: we could also create an ‘alt' group for packet radio 
and gateway the mailing list there. 


This would work, of course, but it wouldn't have a good a propagation 
aS a more mainstream 'rec' group would have. 
- Brian 


Date: Sun, 01 Aug 93 17:43:56 -0400 

From: psinntp!wlnntp.psi.com!usenet@uunet.uu.net 

Subject: Is rec.radio.amateur.packet about to die? Read on. 
To: packet-radio@ucsd.edu 


Has rec.radio.amateur.digital.misc been created yet? The newserver I 
use hasn't created it yet, if it has. 


Thanks, Seth 


Date: Sat, 31 Jul 1993 20:37:34 GMT 

From: usc!sol.ctr.columbia.edu!destroyer!vela.acs.oakland.edu!w8hd!NewsWatcher! 
user@network.ucsd.edu 

Subject: TCP/IP via radio link? 

To: packet-radio@ucsd.edu 


I need some advise... 


What I would like to find is an extension for the Macintosh OS, like 
VersaTerm's SLIP tool, that could be used with MacTCP to provide TCP/IP 
connections via some sort of radio link. 


I don't think I need a TNC and an AX.25 type device/software. I don't want 
to send anything different over the radio link than I would over a regular 
modem link when using SLIP or PPP. 


Any ideas? 
Jim Hebert, K8SS 


jimh@w8hd. org 


Date: Sat, 31 Jul 1993 09:55:18 +0000 

From: news!demon!1londel.demon.co.uk!dave@uunet.uu.net 
Subject: X1J and the DR200 

To: packet-radio@ucsd.edu 


In article <22s7qt$alj@gopher.cs.uofs.edu> bill@gopher.cs.uofs.edu (Bill 
Gunshannon) writes: 

> 

Has anyone with access to the source looked at putting a version 

of X1? on the DR200?? It seems that the dual port box would 

make a great IP gateway between a local LAN and a backbone. 


bill KB3YV 


HVV VV VV 


dropped a line to the author on this and got the following back: 


>Can you post a reply for me saying that I am quite happy to give the 
>source to anyone interested in doing such a version - and that I will 
>also offer assistance in doing it. 

> 

> 

>Please don't post the code yet - it needs changes. 


I have tracked down a local DR200 occupying shelf space so I will have a go 
at it when the source arrives. 


For those who have asked for the beta-test version, note his last comment! 
Dave 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKE 


* G4WRW @ GB7WRW.#41.GBR.EU AX25 * You think xyoux have problems? * 
x dave@llondel.demon.co.uk Internet x What do you do if you x*xarex * 
x gdwrw@g4wrw.ampr.org Amprnet x a manically depressed robot?? * 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKKKK 


Date: Sat, 31 Jul 1993 18:41:58 GMT 
From: dog.ee.lbl.gov!overload.1lbl.gov!agate!howland.reston.ans.net!gatech!emory! 


kd4nc!ke4zv! gary@network.ucsd.edu 
To: packet-radio@ucsd.edu 


References <25223@acorn.co.uk>, <1993Jul129.180807 .13354@ke4zv.uucp>, 
<25256@acorn.co.uk> 

Reply-To : gary@ke4zv.UUCP (Gary Coffman) 

Subject : Re: Packet can't work 


In article <25256@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes: 
>In article <1993Ju129.180807.13354@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) 
writes: 

>>Channel pathology can still be a problem if stations aren't using 
>>p-persistance backoff. Stations can still butt heads again and 

>>again if they use a fixed Dwait and both happen to start during the 
>>window of vulnerability. And they *xwill*x always start during the 
>>window if the channel is busy. Both will try to transmit as soon 

>>as data carrier from a previous channel user drops. So p-persistance 
>>is essential to making a busy channel work, whether it's duplex or 
>>simplex. 

> 

>Right, but p-persistence only helps by deliberately introducing some 
>dead-time, just as polling systems introduce their own overhead. 


If the p-persist parameters are adjusted properly, there is practically 
no dead time. The channel fills to just slightly below capacity and stays 
there. That's been my experience with several stations doing file 
transfers on the channel. The channel stays constantly busy until 

another station joins with a collision. The channel then slows for 

a moment, p-persist only backs off with a packet failure, then 

readjusts so that channel time is again fully occupied. 


>In both cases, the inefficiency introduced is related to the number 
>of users on the channel (since the p-persist coefficient is supposed 
>to be related to the expected load) but it's possibly more convenient 
>to have the central hub adjust the loading than the user's nodes. 

>Of course, this doesn't preclude the user's nodes being adjusted by 
>some other, centralised authority based at the repeater. 


There are several problems with central authority control. The first 
is the problem of stations joining and leaving the group. The second 
is a matter of single point failure. Inactive stations can be "aged" 
out fairly gracefully, but joining the system is more difficult for 
the transient station. There has to be a dead slot available where 
any station can call to join. That waste is there every round of the 
round robin poll. Alternatively, out of band signaling can be used, 
but that's wasteful of spectrum. 


Single point failure is more confusing. If the master station dies 


in a polling system, then the channel dies as every station waits 
it's turn to transmit, but none receives a permission packet. The 
permission packets also represent considerable overhead. In token 
passing schemes, the token can be regenerated by any station after 
a timeout, but it's possible to have multiple tokens circulating 
if care is not taken. With CSMA, these problems don't exist. However, 
if a repeater is in use, it also represents a single point failure 
node that requires user intervention (one of each pair of stations 
going upside down) to work around. That's the primary advantage of 
simplex operation, either no action is required when a station 
dies, or only a reroute operation needs to be done. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


Date: 2 Aug 93 03:19:08 GMT 
From: pacbell.com!amdahl!amdahl!ikluft@ames.arpa 
To: packet-radio@ucsd.edu 


References <23bf£s4INNd1h@network.ucsd.edu>, <pschleck.744051384@cwis>, 
<23h927INNJ4b@network.ucsd.edu> 
Subject : Re: Is rec.radio.amateur.packet about to die? Read on. 


brian@nothing.ucsd.edu (Brian Kantor) writes: 

>Yup, at three years, you're a newbie. You've only been around Usenet 
>since the farcical "voting" process got popular. You seem confused 
>about the power and effect the votes have. 


Oh, I see... ¢:-) 


Since you called us all newbies in your first message on this subject, I'm 
going to have fun deflating your flame... piece by piece. 


I have been using UseNet since 1985 (8 years.) I am not a newbie. Many 
others to whom you aim your statements have been on the Net at least as long. 
You've only heard of me and many of the others for three years because that's 
how long you've been complaining about the FAQs we post. That's about how 
long most FAQs have been around. 


OK, one point of yours has been shot down. 


>Please do try to remember: Usenet is xNOT*x a democracy. The votes 


>are ADVISORY to the administrators of the news systems; there is NO 
>compulsion for any administrator to follow the result of any such 
>result when he believes that to be wrong or against his best interests. [... 


Hmmm... You seem to imply none of us knew how UseNet admins fit into the 
picture. Allow me to establish some credentials in this category since it 
seems that you assume people have no experience when you haven't heard of it. 


I've been pretty closely observing how news administration is done since it 
arrived at the univerity I attended. I've been involved in news admin work 
as an aside from my software development duties ever since starting at Amdahl 
over 3 years ago. I was the leader of the team that set up the amdahl.com 
firewall and news/mail/uucp hub machine on an Amdahl 7300 Unix mainframe. 

So you're not the only one on the block who can see what news looks like on 

a big system. 


Besides, it doesn't take as long as you seem to think for anyone to figure 
out that the news admin sets the policy on local newsgroup creation and 
retention. But don't get the idea that there's any single way to do it 
either - many don't have time to follow news.groups. They'll do whatever 
they please within the limits of their time, disk space, and management. 


We know that. Now you know we know it. Another point shot down. 


>You admit that the "voting guidelines" are only that, and that they 
>weren't equal to the survey that you needed to make, yet you somehow 
>feel you needed to follow them and to follow their inappropriate result. 


What wasn't equal and how's that significant. Surveys and discussion were 
conducted for a month before the 30-day discussion. So that's more time 
than most newsgroups get. 


Also, is the result "inappropriate" just because you don't like it? Only 
at your site. Not necessarily on the rest of UseNet, as you imply. 


Yet another point shot down. 


>And you were told that the tcp people (as surveyed in the tcp mailing 
>list) didn't a newsgroups, yet you went ahead with the proposal, and 
>express surprise at the negative result! 


All inputs were considered, including but not limited to yours. No one 
will apologize if that disappoints you. The transcripts of that discussion 
and the news.groups discussion are xstillx available by ftp if you want to 
see what people thought were the pros and cons on that point. 


The proposal evolved as more inputs were made. The digital radio groups 
received strong support from the packet radio community, expect for your 


Single opposing view. The rest of the opposing views were withdrawn whenever 
anyone mentioned that the packet community appeared to favor it. 


Based on the available information, there is little doubt that it was correct 
to put it up for a vote and accept the outcome. That was done. You should 
accept the part that passed, rec.radio.amateur.digital.misc, because there 

is no other opinion poll which can supersede the vote. 


>Remember that good intentions often pave the path into hell. 


Oh my... what could you possibly mean by that?! %:-) (The horns on that 
smiley seem particularly appropriate to poke fun at that one! heh heh...) 


>I've asked the people on the packet-radio mailing list what they want 

>me to do. If there is some consensus and it seems reasonable, that's what 
>I'll do. I am more interested in the fate of the mailing lists than 

>of the Usenet newsgroups; the mailing lists have always been of more 
>benefit, interest, and importance to me. 


Ah ha! Now we get to the bottom of the matter... (!!!) 


Yes, Brian. You have made everyone repeatedly aware that the UCSD mail lists 
are the most, if not only, important things in your view of UseNet. 


You have opposed everything that is different from how UseNet was 5 or more 
years ago. Open your eyes - the 90's have arrived (years ago.) Things are 
changing. Are you going to adapt or just keep complaining? 


Some things just have to change because of the increasing traffic on 

UseNet and the Internet. For example, you have vocally opposed the FAQs, 
claiming they are a waste of bandwidth. Yet many more people have said they 
appreciate them than all of your complaints combined. Maybe you didn't 
notice the trend a few years ago to make this kind of information available 
on UseNet where people are already looking for it. The trend continues 
because a lot of people think it works. 


Honestly, it looks like you're always trying to be a thorn in the side of 
anyone who's trying to participate in the volunteer postings on the 
rec.radio.amateur newsgroups. I would not be disappointed if you decided to 
xdisconnect*x all your mail lists from the newsgroups. You're behind the 
times and you appear unwilling to try to catch up. 


Frankly, I'm tired of hearing your repetitive whining, Brian. I've tried to 
work with you. I've tried to be polite... I've been patient. Those clearly 
won't work. You need not expect those any more until you show some 
flexibility. 


It can't work any less than the previous approach did. It's soo0000000000 


frustrating to try to work with you. 


>No need to worry about 
>Usenet - it will survive anything even well-meaning people can do to it. 


I know you're aiming that at Paul, me, and others. Are you including 
yourself in that? If so, I agree completely. If not (as your tone implies), 
I suggest you remember that there's more to the world, and UseNet, than any 
Single person's view of it. 


Ian Kluft KD6EUI PP-ASEL Amdahl Corporation, Open Systems Development 
ikluft@uts.amdahl.com Santa Clara, CA 
[disclaimer: any opinions expressed are mine only... not those of my employer] 
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